The Service Oriented Architecture (SOA) is a popular architectural paradigm for the development of software applications. For example, Web services provide the SOA to other applications via industry standard network, interfaces and protocols. The SOA is based on loosely-coupled and standards-based architectures. SOA is one approach to distributed computing that allows networked software resources to be leveraged.
An Enterprise Service Bus (ESB) is an underlying infrastructure for the SOA. The ESB implements the abstract design concept of the SOA. The ESB is an event-driven and standards-based messaging engine that provides services for more complex architectures. The ESB provides an infrastructure that links together services and clients to enable distributed applications and processes. The ESB allows systems to interact through standard transports, such as file transfer protocol (FTP) and hypertext transfer protocol (HTTP), and to provide SOA-based applications. The ESB provides the capabilities of message handling, filtering, data transformation, content-based routing, and message repositories. The ESB provides the above capabilities to a client using a service deployed on an ESB server at runtime that exchanges messages with the client.
The ESB server provides an effective way of processing various kinds of messages and events. When an organization wants a high-performing ESB, the organization will usually run multiple instances of the ESB server (also referred to herein as ESB instances or instances of the ESB) in a cluster configuration, such as illustrated in FIG. 1, and then implements a load balancing technique to distribute processing among the multiple instances. Load balancing is a technique to distribute workload evenly across two or more computers, network links, CPUs, hard drives, or other resources, in order to get optimal resource utilization, maximize throughput, minimize response time, and avoid overhead. In the ESB context, a conventional load balancer, such as a dedicated program, may allocate additional instances of the ESB in a cluster configuration as illustrated and described with respect to FIG. 1. As shown in FIG. 1, all of the ESB instances are the same and include all deployed services. This solution works but some nodes at which the ESB instances are hosted may have unused services deployed because not all the services are used equally. For example, the ESB instances execute all the deployed services (e.g., by calling one or more methods contained in the code that implements the services), regardless of whether the service will be utilized. The services may be system services including invocation support, routing (static/deterministic routing, content-based routing, rules-based routing, policy-based routing), mediation, messaging, process choreography, service orchestration, complex event processing, security (encryption and signing), reliable delivery, transaction management, management (e.g., monitoring, audit, logging, metering), and user defined services. When duplicating the services, each instance of the ESB supports all of the services.